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T he biggest blunder most new Smalltalk developers 
make is improper use of class methods. Many a new 
Small talk convert has implemented major portions of 
a system design using class methods. Well, why not?They 
are easy to access—cal lable from anywhere by any object. 

Tempting, but not a good idea. First, consider your 
system design documents. There is no place on an object 
model for class methods. When you build an object 
model of your system design, the services in a class sym¬ 
bol map to instance methods, not class methods. For 
example, consider the simple class symbol for a product 
vendor as shown in Fig. 1: 

Every product vendor has its own name, address, and 
I ist of products offered. These attri butes that every prod¬ 
uct vendor possesses translate into Smalltalk instance 
variables defined in the ProductVendor class. Every prod¬ 
uct vendor can be asked to provide a quote for a given 
quantity of product. This is a behavior every product ven¬ 
dor provides, so it translates into an instance method 
defined in the ProductVendor class. 

Now at some time during system execution all the 
product vendor objects must be loaded into memory. 
One approach is to write a class method, loadAII, in the 
ProductVendor class. This class method goes out to the 
database and reads all the product vendor objects. A 
class method is used so it can be cal led by a human inter¬ 
face screen or some other process. Great, but where does 
it go on the object model?To show it on the class symbol 
would imply it is an action every product vendor per¬ 
forms—an instance method (see Fig. 2). 

Faced with this problem, most developers invent an 
extension to the notation or discover within the notation 
some obscure demarcation for distinguishing class 


ProductVendor 

name 

address 

productsOffered 

quotePriceForQuantityOfProduct 

loadAII 


Figure 1. Simple class symbol. 


methods from instance methods. Oh boy. If you follow 
this approach, you have an object model with notation 
only you understand that is implemented using global 
functions. That's right, global functions. 

Your design is much less object oriented with class 
methods. Ideally, you want all the functionality in your 
system to be implemented by objects that represent 
things in the real world, or correspond to system compo¬ 
nents. Class methods are a fluke, a side effect of the fact 
that most object-oriented languages need a data struc¬ 
ture to serve as the definition for producing objects, and 
this data structure, typically called a class, needs to have 
behavior so it can produce objects. Making use of this 
fluke is just an acknowledgment that you have system 
functionality you cannot associate with any object in 
your design ... global functionality. 

Another problem arises when requirements change. 
Suppose you want to use the ProductVendor class in two 
different applications—one with an ORACLE database, 
one with a OODBM S. The loadAII method would have to 
be written differently for each application. In fact, every 
time the data representation requirements changed you 
would need a new version of the loadAII method. Ouch. 

So to recap, the problems with class methods are: 1) 
Class methods require new or obscure notation on the 
object model. 2) Class methods make your design less 
object oriented. 3) Class methods decrease the flexibility 
of your system to changes in requirements. 

What to do? What to do? First, learn to recognize that 
wherever class methods abound ... objects are missing. 
In the example, a loadAII class method was used because 
there was no object in the system design responsible for 
loading product vendors. So add one (see Fig. 3). 

Heck, add a bunch... ProductVendorOracleDBA, Product- 
VendorOODMBSDBA. However many you might need, just 
get that loading behavior out of the class method on your 
business domain object and get it into an instance 
method on a separate object. Now in all your future 
applications whenever product vendors need to be 
loaded, create a product vendor DBA of the proper class, 
hook it to the server, and tell it to loadAII. Gee, you could 
even document the loading procedure with an object 
interaction or a scenario diagram, something that would 
be really hard if you were using class methods. 
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ProductVendor 

name 

address 

productsOffered 

quotePriceForQuantityOfProduct 
load All 


Figure 2. An Instance method. 


ProductVendorDBA 


server 

ToadAN 

loadAIISuchThat 


Figure 3. Object for loading product vendors. 

So, system functionality in class methods, particularly 
in a business domain class, indicates objects are missing. 
Here’s when you should use class methods: 

1. Creating new objects. 

Product new 

Date today 
Time now 
perot 

Array new: 10 

Messages new, today, now, perot, new:, correspond to class 
methods that create new objects. The new class methods 
typically create objects with nil or default initial valuesin 
the instance variables. The other methods, such as today, 
and now, create special objects in the class that have 
instance variables preset to meaningful values. 

2. Managingdassvariables. Use cl ass methods to: 

• Initialize, reset, flush class variables 

• Provide read and write access into cl ass variables 

Wow. That’s a short I i st. Wei I, there i s one other ti me you 
might consider class methods, but it is for development 
purposes not system design. 


3. Creating example or test objects. 

Atestobjecthasin its instance variables typical data val¬ 
ues that would exist during a normal system execution. 
Test objects are a great help during development because 
they allow developers to run portions of the system with¬ 
out having to load data, guess at representative data val¬ 
ues, or keep workspaces open with scripts for building 
objects. Here’s how a typical test object method looks. 
Note, how the executable comment within the method 
makes it easy to run. 

ProductVendor class methodsFor: 'examples' 
testObject 

"ProductVendor testObject" 

| vendor| 

vendor :=self new. 

vendor name: 'Vendor X'. 

vendor address: Address testObject. 

vendor addProductOffered: Product testObject. 

vendor addProductOffered: Product test0bject2. 

vendor addProductOffered: Product test0bject3. 

^vendor 

Now do not go off and implement elaborate test scenar¬ 
ios with a slew of class methods; you will be making the 
missing object mistake all over again. Test scenarios will 
vary from application to application, so build separate 
objects to implement your testing procedures. Test ob¬ 
jects are essentially the unit tests from which all test pro¬ 
cedures are built. 

To conclude, guard against class methods creeping in¬ 
to your design. Designs using class methods are not eas¬ 
ily represented within an object model, are less object 
oriented and more functional, and are brittle to changes 
in requirements. Where class methods abound, objects 
are missing. Use class methods for creating new objects, 
managing class variables, and building test objects. K 
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